E2E Tests 🚀
This PR will run tests tagged with: @:critical

^{readme  valid tags}

it is pretty easy to just type something like .positron-server-2 into the setting if you aren't reading carefully, and the behavior is undefined in this case. If the user doesn't specify an absolute path, I think we should resolve the relative path against $HOME by default

Yeah, good idea. I think that as this PR stands right now, the relative path will end up resolving relative to whatever the pwd is configured to be when you first connect via SSH (which is usually $HOME), but since that's less well-defined than just $HOME, I can change the behavior of the setting.

the setting is application scoped but this feels more like a per project/machine thing b/c you probably won't have the same needs for everything you connect to. maybe change the scope?

I am generally confused about setting scopes. (It doesn't help that there's no mention of "application" in the docs!) I ended up choosing application because

• other related settings like remoteSSH.serverDownloadUrlTemplate and remoteSSH.experimental.serverBinaryName are application-scoped
• I convinced myself that having different settings for different users or workspaces could get messy

...Oh, I just found the VS Code version of this setting:

This looks to be application-scoped but the mapping feature is nice. Maybe I'll change the Positron setting to act like this?

if the user specifies a path that they can't write to and we can't make for them, what happens? (think we need better error handling for this than we have today)

We hit this code, which pops up a toast that says something like "could not install server on remote host" and opens the Output panel to the Remote SSH logs, which say mkdir: cannot create directory ‘/opt/test’: Permission denied.

It might make sense to surface any bash-script-level errors better than just log entries with a generic toast, but I think that's outside the scope of this PR.

another idea would be to make the value something you can override with an env var so it could be configured on the host side

do we actually expand tildes in the setting value? (wasn't clear to me but the default uses $HOME; if not, the example shouldn't use them)

The literal text of the setting is inserted into the bash script we send to the server like SERVER_DATA_DIR="<setting>". So if it includes a tilde or environment variable represented as $ENV_VAR, that will be expanded by bash on the server side. I can clarify this in the setting docs.